Hey, I noticed you changed src/languages/en.ts in a PR from a fork. For security reasons, translations are not generated automatically for PRs from forks.

If you want to automatically generate translations for other locales, an Expensify employee will have to:

1. Look at the code and make sure there are no malicious changes.
2. Run the Generate static translations GitHub workflow. If you have write access and the K2 extension, you can simply click: [this button]

Alternatively, if you are an external contributor, you can run the translation script locally with your own OpenAI API key. To learn more, try running:

npx ts-node ./scripts/generateTranslations.ts --help

Typically, you'd want to translate only what you changed by running npx ts-node ./scripts/generateTranslations.ts --compare-ref main

Codecov Report

❌ Looks like you've decreased code coverage for some files. Please write tests to increase, or at least maintain, the existing level of code coverage. See our documentation here for how to interpret this table.

@codex review

@situchan @JS00001 One of you needs to copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

BE PR open @Krishna2323

This is still on hold for BE PR?

No, looks like this was deployed

Please merge main

🤖 Reviewed the diff. The structure is clean — the shared PublicReceiptVisibilityToggle mirrors the existing setPolicyAttendeeTrackingEnabled optimistic pattern well. One blocker and one behavior question before this is mergeable.

🔴 Blocker — missing Spanish translations (will fail CI typecheck)

src/languages/es.ts is typed as TranslationDeepObject<typeof en>, so every key added to en.ts must also exist in es.ts or npm run typecheck fails. This PR adds keys to en.ts but not es.ts:

• src/languages/en.ts:7481 — workspace.upgrade.publicReceiptVisibility (title, description, onlyAvailableOnPlan)
• src/languages/en.ts:7771 — workspace.rules.individualExpenseRules.publicReceiptVisibility / publicReceiptVisibilityHintEnabled / publicReceiptVisibilityHintDisabled

None of these appear in es.ts. Add the Spanish equivalents (get them JaimeGPT-approved per the checklist — the checklist box is ticked but no Slack link is filled in and no es.ts change is in the diff).

🟠 Question — upgrade path vs. Test step 8

The new component adds an upgrade flow that the sibling toggles (attendeeTracking, eReceipts) don't have — PublicReceiptVisibilityToggle.tsx:59-72:

const isUnavailable = !isControlPolicy(policy);
const upgradeDisabledAction = isUnavailable ? navigateToUpgrade : undefined;

Combined with the WorkspaceUpgradePage handler you added, this implies that on a non-Control workspace (with the Rules feature enabled) the toggle renders locked with an upgrade CTA. But Test step 8 says "Open Rules on a Collect/Team workspace — verify the toggle is not shown." Those two things can't both be true.

Which is intended?

• If it should be hidden on non-Control (per step 8), the isUnavailable/navigateToUpgrade/WorkspaceUpgradePage wiring is dead code and should be dropped.
• If it should show a locked upgrade toggle on non-Control, update the test steps to match.

Please confirm the product intent so the extra code and the test steps agree.

🔵 Nits

• Naming: the action is setPolicyReceiptVisibilityPublic while the command/param/onyx field use PublicReceiptVisibility / isReceiptVisibilityPublic word order. Consider setPolicyPublicReceiptVisibilityEnabled to match the WRITE_COMMAND and the surrounding set*Enabled convention.
• In the revamp path withReadOnlyFallback isn't passed, so a read-only Rules user gets a locked switch with no read-only modal on tap. That matches the sibling toggles' behavior in revamp, so it's fine — just calling it out since Test step 9 exercises the read-only case (it's the classic path that shows the modal).

Looks good to me but the text shouldn't flow under the switch toggle, but rather fold to two lines when it's close to the switch toggle. So the text and toggle are more side by side than that the description is below it if that makes sense?

Looks good to me but the text shouldn't flow under the switch toggle, but rather fold to two lines when it's close to the switch toggle. So the text and toggle are more side by side than that the description is below it if that makes sense?

I think how it is currently is actually correct... Based on our Figma component I believe that is the expected behavior. Here's another example from an accounting integration:

@situchan could you please review again?

I think how it is currently is actually correct... Based on our Figma component I believe that is the expected behavior. Here's another example from an accounting integration:

It is, but the way I designed it was meant to be more like a push input. Fine with just using the above but the spacing becomes real odd

I see! Feel free to ignore me then and carry on!

Reviewer Checklist

• I have verified the author checklist is complete (all boxes are checked off).
• I verified the correct issue is linked in the ### Fixed Issues section above
• I verified testing steps are clear and they cover the changes made in this PR
  • I verified the steps for local testing are in the Tests section
  • I verified the steps for Staging and/or Production testing are in the QA steps section
  • I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
• I checked that screenshots or videos are included for tests on all platforms
• I included screenshots or videos for tests on all platforms
• I verified that the composer does not automatically focus or open the keyboard on mobile unless explicitly intended. This includes checking that returning the app from the background does not unexpectedly open the keyboard.
• I verified tests pass on all platforms & I tested again on:
  • Android: HybridApp
  • Android: mWeb Chrome
  • iOS: HybridApp
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
• I verified proper code patterns were followed (see Reviewing the code)
  • I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I verified that this PR follows the guidelines as stated in the Review Guidelines
• I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
• If a new component is created I verified that:
  • A similar component doesn't exist in the codebase
  • All props are defined accurately and each prop has a /** comment above it */
  • The file is named correctly
  • The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
  • The only data being stored in the state is data necessary for rendering and nothing else
  • For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
  • Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
  • All JSX used for rendering exists in the render method
  • The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions
• If any new file was added I verified that:
  • The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• For any bug fix or new feature in this PR, I verified that sufficient unit tests are included to prevent regressions in this flow.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
• I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

@Expensify/design please confirm the layout is correct (switch toggle button, description text positions, vertical padding, etc)

Screen.Recording.2026-07-27.at.9.10.07.PM.mov
When beta not enabled (production behavior):

Screen.Recording.2026-07-27.at.9.11.22.PM.mov

Btw this question was raised because of height change (single line <-> multi line) whenever switch toggles:

I think collect policy case can be tested only after #95310 is merged

🤖 Reviewed the changes. Overall this is a clean, well-structured PR — the shared PublicReceiptVisibilityToggle is a nice de-dup across classic and revamp Rules, the optimistic/success/failure Onyx data is correct, and the upgrade flow is wired up properly. No blocking issues found.

Things I verified

• The disabled/unavailable path is safe: Switch fires disabledAction (not onToggle) when disabled, so a Collect workspace with write access hits the upgrade CTA and never calls SetPolicyPublicReceiptVisibilityEnabled for an unavailable feature. ✅
• The upgrade intro is fully wired — icon: 'ReportReceipt' is a valid illustration (passes the Missing icons guard in UpgradeIntro.tsx), and title/description/onlyAvailableOnPlan keys all exist for feature.id = publicReceiptVisibility. ✅
• Read-only handling matches existing rows: classic passes withReadOnlyFallback (shows the read-only modal), revamp doesn't (locked, like the other revamp toggles). ✅
• en/es and the other 8 locales are all updated. ✅

Suggestions (non-blocking)

1. Automated tests. The author checklist marks "I added unit tests for any new feature or bug fix" as done, but the diff has no test file. A small unit test for setPolicyReceiptVisibilityPublic (optimistic set + failure rollback to the prior value) would lock in the offline behavior. Either add one or uncheck that box.

2. Naming consistency (nit). The identifiers use two different word orders: the action setPolicyReceiptVisibilityPublic and the Onyx field isReceiptVisibilityPublic, vs. the command SetPolicyPublicReceiptVisibilityEnabled, the params file, and the CONST key publicReceiptVisibility. Not a bug, but aligning them (e.g. setPolicyPublicReceiptVisibility / isPublicReceiptVisibilityEnabled) would make things easier to grep.

3. Confirm the Collect intent. Showing the toggle on Collect with an upgrade path is clearly deliberate (per the commit history), just flagging so a reviewer double-checks the product decision that it should render on non-Control Rules at all.

One thing I can't verify from the App repo: that the backend SetPolicyPublicReceiptVisibilityEnabled write command exists/is deployed — worth confirming before this merges.

Codex Review: Didn't find any major issues. 🚀

Reviewed commit: 4020c3fb64

Btw this question was raised because of height change (single line <-> multi line) whenever switch toggles:

Ah I see. I'd say make the change I outlined here and let's see how it feels.

Agree with Jon. Not sure why toggling the switch would change anything to do with the layout though.

Agree with Jon. Not sure why toggling the switch would change anything to do with the layout though.

Because the copy is different.

'Receipts are viewable by anyone with the URL. Access to the report with the receipt is not required.',
'Receipts are only viewable by Expensify members with access to the report containing the receipt.',

Enabled copy has more 1-2 characters than Disabled so it wrapped into 2 lines

Ah thank you, I didn't realize that!

@dannymcclain any outstanding design concerns here?

Did we address @dubielzyk-expensify's comment here?

I'm not super concerned about it since how it works now is how all our other toggle rows work, so if Jon feels strongly maybe we can just address in a follow up?

@Krishna2323 ^?

@JS00001 @Expensify/design update:

Nice! Send it. Jon will be pleased haha.